When developers create a new computerized application, the new application is tested to ensure it functions properly. Automated testing tools are used to run simulations on an application. The results of the simulations indicate whether the application works properly under a variety of predefined conditions. One example of an automated testing tool is IBM's Rational Functional Tester. Although an application will be used to describe this invention, automated testing tools can also be used to test Graphical User Interface (GUI) designs and GUI flows. Developers use the results of the simulations to ensure that the application or the GUI will work properly in the future.
The first step to running a simulation is to record a static test. The developer performs a series of manipulations using the application, as if the developer was a user. The developer defines limits and parameters based on expected user inputs. The recording of the static test is called a “test script.” The developer also sets verification points for the simulation by specifying expected results from a step or series of steps in the test script. The expected results are saved to a “static data store” which also contains data indicating any external applications used by the application when executing the test script. A limitation to using a static test script is that if the computer environment changes after the script is written, the simulation may not reflect the new computer environment. It would be desirable to have an automatic way of updating the static test script to reflect changes in the computer environment at the time the simulation is run.
The second step to running the simulation is executing the series of recorded manipulations from the test script. At each verification point, the functional tester compares the actual results to the expected results in the static data store. When the actual results do not match the expected results the test fails and the simulation ends. When a test fails, it is called an “exception.”
If the simulation ends when an exception occurs, the developer only has enough information to correct the single problem causing the exception. The developer must resolve the issue that caused the exception and run the simulation again before subsequent verification points can be tested. It would be desirable if the automated testing tool could continue the simulation after an exception occurs and identify if the rest of the test script works properly or if there are other problems.
One type of exception that occurs when running simulations is the inability to properly access a computer resource needed by the application when running the test script. This type of exception is not caused by bad coding, but by changes in the computer environment such as the computer resource having been moved, renamed, replaced, updated, or reconfigured. Information related to the configuration of and the relationships between computer resources on the computer environment is often stored in a data base, such as a Configuration Management Data Base (CMDB). Information related to each resource stored in the CMBD is called a “Configuration Item” (CI).
A need exists for a method of using a data base, such as a CMDB, to enhance software testing simulations by ensuring the simulation can be executed to the fullest extent. The test script can be updated at run-time using the data base to accommodate changes in the computer environment. If an exception occurs at a simulation verification point, the automated testing tool can identify a related resource, as indicated in the data base, to repeat the simulation verification point and complete the simulation.